Pipeline

Redis客户端执行一条命令分为如下四个过程：1发送命令,2命令排队,3命令执行,4返回结果其中1+4称为Round Trip Time（ RTT,往返时间）Redis提供了批量操作命令（ 例如mget、 mset等） ， 有效地节约RTT。 但大部分命令是不支持批量操作的.

Pipeline（ 流水线） 机制能改善上面这类问题， 它能将一组Redis命令进行组装， 通过一次RTT传输给Redis， 再将这组Redis命令的执行结果按顺序返回给客户端.

上图是使用了pipeline 执行了n次命令，整个过程需要一个RTT

Pipeline执行速度一般比逐条执行要快。客户端和服务端的网络延时越大， Pipeline的效果越明显。

pipeline 和原生批量命令相比，原生批量命令是原子的， Pipeline是非原子的。原生批量命令是一个命令对应多个key， Pipeline支持多个命令。原生批量命令是Redis服务端支持实现的， 而Pipeline需要服务端和客户端的共同实现。

事务与Lua

为了保证多条命令组合的原子性， Redis提供了简单的事务功能以及集成Lua脚本来解决这个问题。

Redis提供了简单的事务功能， 将一组需要一起执行的命令放到multi和exec两个命令之间。 multi命令代表事务开始， exec命令代表事务结束， 它们之间的命令是原子顺序执行的.如果要停止事务的执行， 可以使用discard命令代替exec命令即可。

有些应用场景需要在事务之前， 确保事务中的key没有被其他客户端修改过， 才执行事务， 否则不执行（ 类似乐观锁） 。 Redis提供了watch命令来解决这类问题.

可以看到在multi前执行了watch key 命令，在事务期间有客户端修改了key的值，所以事务不会执行。Redis提供了简单的事务， 之所以说它简单， 主要是因为它不支持事务中的回滚特性， 同时无法实现命令之间的逻辑关系计算。

发布订阅

Redis提供了基于“发布/订阅”模式的消息机制， 此种模式下， 消息发布者和订阅者不进行直接通信， 发布者客户端向指定的频道（ channel） 发布消息， 订阅该频道的每个客户端都可以收到该消息。

常用命令

1
2
3
4
5
6
7
8
9
10
11
12
13
Redis主要提供了发布消息、 订阅频道、 取消订阅以及按照模式订阅和取消订阅等命令
# 发布消息
publish channel message  返回订阅者人数
# 订阅消息
subscribe channel [channel...]
# 取消订阅
unsubscribe channel
# 查询至少有一个订阅者的频道
pubsub channels pattern
# 查看频道订阅数
pubsub numsub channel

客户端在执行订阅命令之后进入了订阅状态， 只能接收subscribe、psubscribe、 unsubscribe、 punsubscribe的四个命令

和很多专业的消息队列系统（ 例如Kafka、 RocketMQ） 相比， Redis的发布订阅略显粗糙， 例如无法实现消息堆积和回溯。 但胜在足够简单， 如果当前场景可以容忍的这些缺点， 也不失为一个不错的选择。